ASME's Mechanical Engineering Toolkit 1997 December

home *** CD-ROM | disk | FTP | other *** search

/ ASME's Mechanical Engine…ing Toolkit 1997 December / ASME's Mechanical Engineering Toolkit 1997 December.iso / edu_comp / listserv.exe / LISTSERV.DOC < prev

Wrap

Text File | 1993-05-29 | 41KB | 784 lines

Return-Path: <LISTSERV@xxxxx.BITNET> Date: Fri, 29 May 1992 22:25:29 -0500 Subject: File: "LISTSERV MEMO" being sent to you Revised List Processor (LISTSERV@FRECP11), Release 1.5d ---------------------------------------------------- (c) Eric Thomas 1986 Ecole Centrale de Paris You can skip the introduction and go to the commands description by instructing your text editor to locate the string "GENCOM" (eg "/GENCOM" under XEDIT). *********************************************** * What is LISTSERV? What is Revised LISTSERV? * *********************************************** LISTSERV stands for "list server"... but what does that mean? Origi- nally, LISTSERV was a mailing-list server which was designed to make group communication easier. The first version of LISTSERV, written by EDUCOM and installed at BITNIC under the userid of LISTSERV, offered basic "mail-exploding" capabilities. People with a common interest (eg network protocols, issues related to handicapped people in education, system administration problems) were grouped in a list which was then stored on LISTSERV. They could then communicate with each other by sen- ding mail to a special network address (eg UG-L@BITNIC). Any piece of mail sent to these special user-ids would then be automatically distri- buted by the list server to each and every person on the list. You did not have to know all the names and network addresses of the people sub- scribed to the list. The usual messages sent by the mailing systems when mail has been successfully delivered were sent to LISTSERV -- a big relief for the sender... People could join a list by asking the "list coordinator" (actually the person who maintains the list server) to be added to the list and it was a very convenient way to meet people and participate in interesting discussions/forums. As LISTSERV became popular and the number of lists grew, it started to show some weaknesses and limitations. Even though LISTSERV was ins- talled at a central site, it generated a very important traffic because there was an important number of people from distant nodes in the net- work. If there were ten persons of the same node on a given list, it sent ten copies of each piece of mail to the node. List maintenance be- came a problem because of the evergrowing number of requests for sub- scription. Mail headers became bigger and bigger, and 30 lines was not an uncommon size. Some non-VM users had troubles accessing the server, could not send commands nor mail to it and received files in a format their system was not able to read. Non-mail files could not be sent to a list. The server was often caught looping on a rejection mail from a network mailer. No help or command description was available, and unknown commands were ignored. Sending a "HELP" command did not produce any kind of answer from the server. Revised LISTSERV is a brand new list processor which was developped at the Ecole Centrale de Paris in France to overcome the restrictions and lack of functionnality of the first version of LISTSERV. It retains the basics of the old LISTSERV and provides good ascending compatibili- ty, while offering more sophisticated functions, helpfiles and more user-friendliness. Revised LISTSERVs can be linked together to create peer lists for better network efficiency in a way that is nearly trans- parent for the user. Users can send a command to the server to subscri- be to a list. For more information about the differences between the BITNIC-type LISTSERV and Revised LISTSERV, send the following command to the nearest Revised LISTSERV: Info FEATures (or just: I FEAT) ! Additionally, Revised LISTSERV provides powerful file-server func- ! tions which allow list moderators to make pertinent datafiles and/or ! programs available to the subscribers of their lists. For more informa- ! tion on this new feature, issue the following command to the nearest ! Revised LISTSERV: Info FILE ******************************************************************** * Terminology and general information about LISTSERV documentation * ******************************************************************** All the information guides available from LISTSERV follow the IBM convention that changes since last release are indicated by a vertical bar in column one. These vertical bars are "reset" when the release number is incremented. Post-releases (indicated by a lowercase letter following the release number, eg "1.3c") will have exclamation marks in column one to indicate the changes from the base release (1.3 in our example) and to differentiate them from the vertical bars that must be reset when the next version (1.4 in our example) is released. Temporary restrictions/warnings will be indicated by a ">" sign in column one and will stay until the restriction is removed or the warning is no longer applicable. Backwards compatibility of all documented features will be kept across release changes unless technically impossible (eg a feature which is discovered to be incompatible with system security). Applica- tions programmers should be careful not to use any feature or command which is not documented since these are subject to change without noti- ce. All throughout the LISTSERV documentation, several terms will be used to refer to distribution lists, mailing systems, etc. Here is a short definition for some of them: "Distribution list", "LISTSERV list", "list": this is a list of per- sons to be used by LISTSERV to distribute mail and/or program files. It can be reviewed by sending a "REView" (qqv) command to the server "List title": this is the "title" of the list, eg "IBM 7171 protocol converter list". It appears in the "Sender:" field of every piece of mail distributed to the list. "List name": this is the 1-8 characters name by which a distribution list is identified to the server. It will often end in "-L", eg "CHAT-L", "UG-L", etc. "List userid": this is the network address/userid@node/mailbox to which mail and files must be sent in order to be redistributed to the list. The first part ("userid") will always be the list name (see above), while the second part ("node") is the node name of the LISTSERV server. Examples: CHAT-L@DEARN, UG-L@BITNIC. The domain name (if required by your mailing system) is always ".BITNET" "LISTSERV userid": this is the network address of the LISTSERV ser- ver, eg LISTSERV@FRECP11. The userid will usually be LISTSERV, but could be something else due to accounting conventions or suchlike. This is the network address you must send commands to. "List owner": the person(s) who maintain the list and who have autho- rity to perform list-maintenance functions. You will sometimes get a message saying that "Your request has been forwarded to the list owner". "List editor": the person, if any, who reviews material sent by users to the list before allowing the server to distribute them. If the list you send mail to is controlled by an editor, you will get a mes- sage saying that "Your mail has been forwarded to the list editor". Most distribution lists do NOT have an editor and mail received by the server is distributed "as is". "File format": the "format" in which a computer file is transmitted across the network. There are several formats which all have limita- tions or flaws, and are not necessarily supported by all operating systems. LISTSERV can send files in five different formats: Punch, Disk Dump, Card Dump, Netdata and Listserv-Punch (issue an "Info LPunch" command for more information on the latter). It accepts only three formats as input: Punch, Disk Dump and Netdata. > Card Dump format will be accepted as input in a future version. > There is no need to support Listserv-Punch format as input. ******************************************************************* * Who should I contact if I have a problem with Revised LISTSERV? * ******************************************************************* In much the same way as hierarchy does not exist in Revised LISTSERV lists (all the servers are peers), there is no hierarchy in the LIST- SERV "management", but three complementary categories of persons: - The list owners: each list will have one or more owners, who are authorized to add or remove people from the list, change the list attributes, etc. They will have this authority on all the peer LIST- SERVs serving their list, and can be considered as "list managers". They are the persons to contact if you have a problem which is speci- fic to a particular list, eg your name being misspelled in the mail header ("To:"), your not being able to send mail to the list, etc. Their name and network address appear in the header of the list definition file (which you can obtain by sending a "REView" command to the server -- see below) under the keyword "Owner=". - The "postmasters": each LISTSERV will have one or more postmasters (send a "RELEASE" command to get their names and network addresses). Postmasters are usually systems programmers and are the people who maintain the list servers and make sure they operate properly. They create and delete lists on their servers but do not maintain them -- that's what list owners are for. They have full authority over their own server and all of its lists, but this authority does not usual ly extend to other LISTSERVs. This means that even though they can modify the copy of any list on their server, they will not be able to affect peer lists on other servers (if any). They do not qualify for list maintenance, unless the list has no peer. Being system administrators, postmasters are usually pretty busy and it will probably take them longer to answer a question than list owners. It is therefore your interest to make sure that you do not send them complaints that ought to be directed to list owners, and they will be thankful for the time you are saving them. Typical questions that should be sent to postmasters are: "LISTSERV is not logged on, is it normal?", "Here is a copy of a piece of mail I sent to LISTSERV and it said it was not valid, why?", etc. - The LISTSERV coordinators: their names, network addresses and task are defined in LISTCOOR MEMO (send an "INFO COORD" to obtain it). Basically, they (try to) provide technical help information to the postmasters, assist new LISTSERV owners in installing the code, coordinate the placement of the servers and distributed lists on the network and correct bugs in the software. They have no special autho rity or privilege on the LISTSERVs or their host systems and there- fore do not qualify for list or server maintenance. They should be contacted mainly by postmasters, and only for reporting bugs, sugges ting improvements to the software and for questions that the owners/ postmasters were not able to answer. They should of course be con- tacted for obtaining a copy of the LISTSERV code. The following 3 sections are designed to help non-BITNET or non-VM/SP users in sending commands to LISTSERV and mail to distribution lists. If you are on a BITNET VM system and you are familiar with this concepts, just do a "/GENCOM" command to skip to the commands description. **************************************** * How can I send commands to LISTSERV? * **************************************** Commands can be sent to LISTSERV in three basic ways: interactive messages, mail, and non-mail files. The distinction between mail files and non-mail files is very important on some systems and inexistant on others; some systems provide only mail files, and some will only have normal files. In the following discussion it will be assumed that you want to send an "Info GENintro" command to LISTSERV at FRECP11 (or LISTSERV@FRECP11.BITNET in RFC822 terms). A) Interactive messages Interactive messages is a facility that is not available to all sys tems; besides, only computers which are directly connected to BITNET can send interactive messages. However, this is the fastest and most convenient way of sending commands to LISTSERV: all you have to do is send it a message with the command text as message text. Example: "*message* Info GENintro", where "*message*" is the command that must be used on your system to send an interactive message to LISTSERV at FRECP11. - On VM/SP systems, this command is "TELL LISTSERV AT FRECP11", ie what you must do is "TELL LISTSERV AT FRECP11 Info GENintro". You could also use CP SMSG rscs MSG FRECP11 LISTSERV Info GENintro, where "rscs" is the name of the RSCS virtual machine at your site. - On MVS systems with TSO/E, this command would be TRANSMIT or XMIT: "TRANSMIT FRECP11.LISTSERV NOPROLOG" When the message text screen is displayed, enter "Info GENintro" as first text line and press PF3 to send it. - On some JES2 systems, the command could be TO, VMSG or XMSG, depen ding on the local implementation: "TO LISTSERV@FRECP11 Info GENintro" - On VAX systems the command would be "SEND" or "SEND/MSG": "SEND LISTSERV@FRECP11 Info GENintro" - Other systems might, or might as well not, have a command for sending interactive messages. Please send any appropriate informa- tion to the author for inclusion in this help file, other users will be thankful for the hint. B) Mail files Those systems which do not have interactive messaging capabilities will usually have a mailing system (although this is not necessarily the case). "Command jobs" can be submitted to LISTSERV via RFC822, PROFS, or IBM NOTE formatted mail. Systems which are not capable of sending mail in any of these standards must resort to the third method (see below). Command jobs can also be used by people on sys- tems which do have interactive messaging capabilities for the usual reliability reasons (messages can be lost in a line glitch while files are *much* safer), and also because command jobs allow several commands to be submitted at once and give better control on their output. They are ideal for commands generated by programs or servers, as opposed to commands sent by human persons. | You can obtain a detailed description of the commands-job feature | by sending an "INFO JOB" command to LISTSERV. To send a command to LISTSERV via mail, all you have to do is send mail to the LISTSERV mailbox and type in the command text as first line in the mail body or note or whatever it is called in your sys- tem. You can enter additional commands if required, as long as you type each command on a separate line. You will get a reply via RFC822 mail, regardless of the mail agent you used to submit the command. - All VM systems can send IBM NOTEs by issuing a "NOTE LISTSERV AT FRECP11" command. Issue a "HELP NOTE" command for more information on the IBM NOTE command format. - VM systems equipped with a Crosswell mailer can send RFC822 mail by issuing a "MAIL LISTSERV@FRECP11" command. The subject field is ignored and needs not be specified. - PROFS users will have no problem finding out how to send PROFS mail to LISTSERV; however, the piece of mail must be sent as MAIL and not as a DOCUMENT. Documents cannot be sent to LISTSERV because LISTSERV is not a PROFS user. - Note: Netdata files in NOTE format generated by MVS systems are not considered as "mail" files unless they contain an IBM NOTE formatted header, which is usually not the case. You should there- fore expect them to be processed as non-mail files when sent to the LISTSERV userid. - There are other commands on other systems of which the author is not aware of. Any information would be appreciated. C) Non-mail files Those systems which do not have interactive messaging capabilities nor mailing facility will be able to transmit normal files, otherwise ! they would not be on a network... To submit a command job to LIST- ! SERV via non-mail file, all you have to do is to prepare a file (or ! dataset) containing the required commands, one command at a line, and !> send it to the LISTSERV userid using the appropriate command. The !> "//" trick which was mandatory with the previous releases of LISTSERV !> is no longer required to identify the file as a command job; it will !> of course still be accepted (and may even speed up command processing !> under certain conditions). - On VM systems the command is "SENDFILE filename filetype TO LISTSERV AT FRECP11". There are a lot of other specialized com- mands depending on the format you wish to use, but SENDFILE will work. Please note that CARD format is not accepted as INPUT to LISTSERV, although it does know how to generate it if specifically requested (see "F=" keyword description). - On MVS systems the command will usually be: "TRANSMIT FRECP11.LISTSERV DATASET(dsname)", where dsname is the ! name of the dataset containing the command lines. Most MVS systems will also accept the following job: // EXEC PGM=IEBGENER //SYSUT2 DD SYSOUT=A,DEST=(FRECP11,LISTSERV) - On Multics systems the command is "sdm" and you must specify a destination of LISTSERV at node FRECP11 when prompted to enter it. ! You must then enter "Info GENintro" as mail contents. ****************************************** * How do I send mail to a LISTSERV list? * ****************************************** To send mail to a LISTSERV distribution list, you will have to know the network address of this list. In the following discussion we will assume that you want to send mail to "SAMPLE-L@FRECP11.BITNET" (or, in IBM terms, SAMPLE-L at FRECP11). Mail can be sent to a distribution list in either of the two following ways: A) Using a mailing system If your system is equipped with a mailing facility, all you have to do is send mail to the network address mentioned above. Refer to the information in the previous section for a description of the command to be used on your system. Note: MVS NOTEs in Netdata format fall in this category, even though they do not have a valid IBM NOTE formatted header. LISTSERV will ge- nerate a standard header and insert it on top of the note. B) Without any mailing system If your system is not equipped with a mailing facility, you will have to resort to files. Note that LISTSERV distributed mailing is primarily designed to work on systems who DO have a mailing facility; | sending mail as a normal file is always possible (see below) but can | be quite tedious. | Mail can always be sent to a distribution list by means of the | DISTRIBUTE MAIL command. To do so, you must prepare a distribution | job as indicated in LISTDIST MEMO (you can obtain this memo by sen- | ding an "INFO DIST" command to LISTSERV) with the list userid as one | and only destination, and a valid RFC822 mail (header + text) as | "data". This method should be used only if the network interface in | your system is so poor that no other method can be used. To send mail to SAMPLE-L@FRECP11, you will have to prepare a file named "anything NOTE", "anything.NOTE", etc, as dictated by your system's file naming conventions. The file name can be anything while the file type/extension/whatever must be "NOTE" (all caps please). This file must contain the text to be distributed to the list, and nothing else. It must be sent "as is" to SAMPLE-L@FRECP11.BITNET, using the appropriate method. LISTSERV will generate a header and add it on top of the file. ******************************************************* * How do I send files to LISTSERV for redistribution? * ******************************************************* To send a file to LISTSERV for redistribution, all you have to do is to send the desired file "as is" to the list userid. No header should be inserted, and no particular name is to be used. The only restriction on the file name is that the filetype/file-extension/whatever it is ! called on your system must not be "MAIL" nor "NOTE". The only restric- ! tion on the contents of the file is that it must not be a Netdata NOTE ! NOTE file nor a PROFS-mail formatted file (otherwise it would be classified as a mail file). In some instances where the list owner suspects that files might in- voluntarily be sent to the list userid although they are not destined for being redistributed, he will have enabled an additional test to be performed on the files before redistributing them. In that case the server will expect files destined for actual redistribution to have a "FORM" value of "REDIST" (or "QUREDIST" if you want to trigger the "Quiet file transfer" feature installed at some RSCS sites). This is indicated by a "Formcheck= Yes" keyword in the list header (send an "Info KEYwords" for more information on list control keywords). Not all systems allow the user to control the FORM value of network files. On a VM system you would have to issue a "CP SPOOL PUNCH FORM REDIST" before issuing the SENDFILE command. On a MVS system you would have to expand the SYSOUT= parameter of the IEBGENER dataset: SYSOUT=(A,,REDIST) *********************************************** * Commands description (non-privileged users) * ---> GENCOM <--- *********************************************** A description of command-keywords format (eg "F=") can be found at the end of this section. Please refer to it for more information on how, where and when to specify these keywords. Info <? | topic> <F=fformat> Sends you an information file like this one. Use "Info ?" for a list of topics. Please note that some of the documents available through the INFO command are restricted to certain categories of users. Help Sends you a brief description of the most useful commands, along with the names and network addresses of the server's postmasters. List <Detailed | Long | Short> <F=fformat> Get a description of all lists. The default option is "Short", and will send you a brief description of each list (via messages). The "Long" and "Detailed" options are synonyms and will send you the "header" por- tion of each list (via file). Query listname Displays your list distribution options for the corresponding list. Refer to the SET command description for more details on the meaning of these options. SUBscribe listname <your_full_name> SIGNUP Use this command to subcribe to a list. You will be automatically added to it unless the list owner has disabled this option, in which case he will be sent a request-for-addition note. If you have misspelled your name when issuing this command in the first place, you will be able to correct it by re-issuing it without having to sign off from the list first. In that case no notification is sent to the list owner. Note that it is not necessary to supply your full name if you have already signed up to another list of the same server. The name you provided on your first signup command will automatically be used for the new subscription. Also note that you will always be able to issue a signup command to correct your name, regardless of the list being open for au- tomatic subscription or not: as long as you are already on the list, the SUBSCRIBE command is not disabled (unless the list is set to "Validate= All commands" to protect you from UREP hackers and suchlike who might issue a SUBSCRIBE command "from" you and change your name to something you would not want to see in front of your userid; in that case, your request will be forwarded to the list owner). | In the case that the list has one or more peers and that the server you | are sending your SUBscribe request to is not the nearest to your node, | it will automatically determine the nearest host server for the list | you are subscribing to and forward your request to it. This applies | only if you are not yet subscribed to the list, of course. SIGNOFF listname UNSubscribe This is the counterpart of the SUBSCRIBE command. Note that you can remove yourself from any list you have been added to, unless it is specially protected by a "Validate= All commands" keyword. Whether you have subscribed to the list yourself or you have been added to it by the list owner is irrelevant. SET listname options Mail/NOMail Files/NOFiles ACK/NOACK/MSGAck Changes your distribution options for the specified list. You can spe- cify more than one option if desired. The previous settings will be retained unless specifically changed, ie if you want to change only one of the options you do not have to specify the settings of the options you do not want to change if they differ from the standard ones. If the list is protected by a "Validate= All commands" keyword, your command will not be executed but it will be forwarded to the list owner. Mail/Nomail indicate whether you want to receive mail from this list or not. The default value is "Mail", of course. Files/NOFiles indicate whether you want to receive non-mail files from the list or not. The default is "Files", but it is recommended that no more than one person per node has this option active on any given list, for obvious network efficiency reasons. ACK/NOACK/MSGAck define the mode in which acknowledgements for mailing or file distribution are to be sent to you. ACK is the default and in- dicates that you want a file acknowledgement (short mail file which in- cludes some statistics on the mailing). NOACK directs the server not to send out any acknowledgement; a single message will be sent to you when the file has been processed, but nothing else. MSGAck indicates that you are interested in the statistics report contained in the acknowled- gement but want it sent to you as messages rather than mail. It is pro- bably the best alternative for local lists (ie lists comprised of users from your local node only). REView listname <(options> <F=fformat> LOCal Msg Countries Short NOHeader Sends you the (formatted) contents of a list. Private lists cannot be ! reviewed by users who do not appear on it. However, the header of the ! list (without any information about the subscribers) will still be sent ! to you even if you are not authorized to review the list, as long as ! you would qualify to obtain this header by means of a "List Detailed" ! (qqv) command. The command will be automatically propagated to all the linked servers, if any, so that you get the complete list of all the persons who are subcribed to the list, not just the local subcription. For a descrip- tion of the keywords defined in the list header, please issue an "Info KEYwords" command to LISTSERV. ! If the list is a "centralized" one, ie a list without any peer, the ! output of the REVIEW command will have a fileid of "listname LIST". If ! the list is found to have one or more peers, the file will be sent as ! "listname nodeid" so that a different fileid is generated for each peer ! list. This will make it easier to keep a copy of the list on your disk. The "LOCal" option indicates that you want only the list of subscribers served by the local LISTSERV and that the command should therefore not be propagated to the peer servers. The "Msg" option causes the command output to be sent to you via inter- active messages, unless it is larger than 30 lines. The "Countries" option indicates that you want a summary of the number of subscribers in each country, sorted by country name. The "Short" options causes the list of subscribers not to be sent to you: only the list header and possible country summary is sent out. "NOHeader" is the counterpart of "Short" and suppresses the list header but not the country summary nor the list of subscribers. Specifying both "NOHeader" and "Short" is valid and will display only the number of persons subscribed to the list, and possibly the country summary. STats listname <(LOCal> <F=fformat> Sends you the statistics report for the desired list. Note that statis- tics may have been disabled for the list, or may not be available to everybody. The report will indicate the total number of mailing opera- tions, the number on (non-local) outbound mail files, the number of (non-local) outbound 80-lines records and possibly the resulting net- work load in "link.kbytes". A link.kbyte corresponds to one kbyte of data being transferred across one link, 512 bytes of data being sent over two links, etc. When this measurement is enabled, the server will compute the distance between itself and all the recipients of the mai- ling operation and compute the exact "link.kbyte" amount. Since this operation takes a relatively important amount of CPU time and requires relatively large data files, it may have been disabled by the postmas- ter in some cases. The "LOCal" option indicates that the command is not to be forwarded to the peer servers linked to the list. The default is to propagate the command to all the servers housing a peer copy of the list. GET fn ft <filelist_name> <F=fformat> SENDME ! ! Sends you the requested file provided you are authorized to retrieve ! it. A more detailed description of this command, including information ! about the optional "filelist_name" operand and the general structure of ! the FILELISTs can be found in LISTFILE MEMO (send an "Info FILE" com- ! mand to obtain it). ! ! Synonyms have been defined for the GETND, GETDD, GETPP and GET80 com- ! mands of Netserv. "GETND xxxx" is translated to "GET xxxx F=Netdata", ! etc. Note that in this implementation, GETPP and GET80 are strictly ! equivalents and will cause the file to be sent in Listserv-Punch format ! if its logical record length is greater than 80. Send an "Info LPUNch" ! command to LISTSERV for more information about Listserv-Punch format. ! !>Note that the Netserv "prologtext" feature is NOT yet supported on the !>GET command. INDex <filelist_name> <F=fformat> ! ! Sends you the specified filelist (defaults to LISTSERV FILELIST). This ! command is strictly equivalent to "GET filelist_name FILELIST" and has ! been made available for compatibility with other file servers on the ! network. PW ADD new_password ! CHange old_password new_password ! DELete old_password ! ! This command allows you to define yourself a password for use with LIST ! SERV, change that password, or delete it if you no longer need it. Note ! that the PW ADD function may have been disabled or restricted to a cer- ! tain category of people by the local LISTSERV management. Please con- ! tact the local LISTSERV management, not the author, if you find youself ! unable to use the PW ADD and think you ought to be able to use it. ! ! A more detailed description of this command and the use of passwords in ! LISTSERV can be found in LISTAFD MEMO (which you can obtain by means of ! an "Info AFD" command). AFD ADD filename filetype <filelist_name> PW=password FUI DELete filename filetype <filelist_name> PW=password ! GET filename filetype <filelist_name> ! List ! Query ! ! This command allows you to subscribe to a file or package which you are ! normally authorized to retrieve from the server by means of a GET com- ! mand (qqv). AFD/FUI DELete will remove your subscription to one or more ! files/packages (wildcard characters are accepted), while AFD/FUI List ! or Query will list the files/packages to which you have subscribed. The ! GET option allows file owners to request a list of people who have sub- ! scribed to their files. ! ! AFD refers to "Automatic File Distribution", ie automatic shipment of ! the updated file, while FUI refers to "File Update Information", that ! is notification of the update without the new file being automatically ! shipped to you. There are two different commands, FUI and AFD, with a ! (nearly) identical syntax, and two independent lists, one for FUI and ! one for AFD. ! ! A more detailed description of this command and the use of passwords in ! LISTSERV can be found in LISTAFD MEMO (which you can obtain by means of ! an "Info AFD" command). ! ! Note that the Netserv "prologtext" feature is supported on the AFD ! command. See LISTAFD MEMO for more information. PUT filename <filetype <filelist_name <NODIST>>> ! <PW=password> <LRECL=nnn> <RECFM=V|F> <"parameters"> ! ! This command allows file owners to store a file in the server. The ! default filetype is "LIST" and causes a normal list-storing operation ! to be performed (this can be useful for list owners whose networking ! system does not allow them to send the file with a spool filetype of ! "LIST"). Note that the spool fileid is completely ignored by the PUT ! command. "NODIST" indicates the file should not be distributed to the ! other servers (in case the file is not a local one). The optional para- ! meters may be required for files which receive special handling -- con- ! tact the local LISTSERV operation staff if you have any doubt on this. ! ! A more detailed description of this command can be found in LISTFILE ! MEMO, which you can obtain by means of an "Info FILE" command. RELEASE Sends you information messages containing the release number of the server and the names and network addresses of the server's postmasters. This is the same information that you obtain from a HELP command, but without the help information itself. > Servers which have not yet installed version 1.4 or better of LISTSERV > will not understand that command. SERVE userid@node | | Returns service to a disabled user. To prevent loops and 'message wars' | to occur, LISTSERV will automatically "disable" a user after receiving | 10 invalid commands from him. Further commands will be completely igno- | red without any error message being sent back, until service is resto- | red from another userid/account by means of the SERVE command. DISTribute < <MAIL> <DD=ddname> <FROM=userid@node | FROM=DD=ddname> | <ACK=NOne | MAIL | MSG> <TO DD=ddname | u@n1 <u@n2...>> > ! <PRIOR=* | nn> <INFORM=MSG | MAIL> | | A complete description of the DISTRIBUTE command can be found in LIST | DIST MEMO, which can be obtained from LISTSERV by sending it an "INFO | DIST" command. ********************************************************** * Command keywords: why, when, and where to specify them * ********************************************************** Command keywords provide a means whereby some command-independent information can be passed to the LISTSERV "supervisor" in a standard way. Command keywords will be accepted on ANY LISTSERV command and they will always be processed the same way; however, there will be commands for which some or all of the accepted control keywords are irrelevant. Only relevant keywords are listed in the commands description (see above). All command keywords can be specified anywhere in the command-text, AFTER the command name itself. They can appear at the end, in the mid- dle of the arguments of before the command arguments. A command keyword is an expression of the form: " keywordname=keywordvalue " (the double- quotes are not part of the keyword expression). The blank before the keyword name is mandatory, while there must be NO blank between the keyword name and the equal sign. There can be one or more blanks between the equal sign and the keyword value. The reason for these res- trictions is to avoid "finding keywords where none was intended". Valid examples: "REV F=Netdata CHAT-L (Countries" "REV CHAT-L F= Netdata (Countries" "REV CHAT-L (Countries F= Netdata" Examples of improperly specified keywords: "F=Netdata REV CHAT-L" (keyword must appear after command name) "REV CHAT-L F = Netdata" (blank between "F" and the equal sign) "REV CHAT-LF=Netdata" (missing blank before keyword name) ********************************************* * Description of available command keywords * ********************************************* Unrecognized keywords will be left unhampered in the command line, ie you can use equal signs in command arguments without problem. Since key words are processed before the command itself is analyzed, specifying an improper value for a keyword will cause the command to be terminated immediately without any further checking. F= Netdata | Disk | Card | Punch | * This keyword controls the "format" in which files will (possibly) be sent to you. The default value, ie the value taken if the keyword is omitted, is "*", which instructs LISTSERV to use the default file for- mat defined by your system administrator in the BITEARN NODES database. This format will (hopefully) be the most efficient format that your operating system is able to handle. However, if this default format is incorrect or if for some other reason you want files to be sent to you in another format, you can specify a "F=" keyword to override the default specification. Only the first letter of the format needs be given. "Punch" format is automatically changed to "Listserv-Punch" if the file being sent to you is larger than a card image (80 characters). PW= password This keyword provides a means whereby a "password" can be specified on a LISTSERV command. The password to be given will be different depen- ding on the category of command (list-maintenance, server-operation, server-maintenance) and will be processed accordingly. Generally spea- king, the command will be rejected or only partially honored if the password is incorrect. General user commands will never require any password, and thus the "PW=" keyword is irrelevant for general users. -------------